Summary

I submitted an open-source contribution to the Open Charging Network.It is an implementation of the Open Charge Point Interface protocol (OCPI) HubClientInfo module. It was fun working on it and I was pushed improve my abilities. The pull request that I submitted is here: https://bitbucket.org/shareandcharge/ocn-node/pull-requests/15 The request is marked as declined as the code was merged into another branch.

Open Charging Network and OCPI

The Open Charging Network (OCN) is a project by Share&Charge. From their wiki: "The Open Charging Network is an open and decentralized network for the implementation of digital eMobility services."

I found the OCN when looking for organizations that I could work with to help with climate change. Share&Charge was one of the few green energy companies that I found that had an active open source repo and great documentation. Kudos to them! 👍

I like the OCN is using OCPI, with is open-source protocol for their work. I think that the more open-source, the better as far as electric vehicle innovation is concerned.

Technical Notes

Kotlin and SpringBoot

I hadn’t used Kotlin or SpringBoot prior to this contribution but I throughly enjoyed both of them. I found Kotlin’s syntax to be very intuitive and pleasant to write and SpringBoot’s framework to be powerful and clear. 🏖️

OCPI HubClientInfo Implementation Decisions

The HubClientInfo is a cool module of OCPI, as it is somewhat of a side module that reacts to the usage of other modules. Its role is to notify other parties when the connection status of a network party changes.

Reacting to the usage of other modules

The HubClientInfo module seemed like an ideal place to pub/sub or events so as to not couple the modules together too much. Luckily SpringBoot has an awesome "Domain Events" feature that fit perfectly (and I was glad to use it as I had been reading about Domain Driven Design recently). Both a fitting and fun solution!

Connecting on request/response

An interesting feature of the HubClientInfo module is that it a party is considered connected if a request or response is received from that party. To me, this implied subscribing to "request/response received" events or intercepting each request/response. I thought using Aspect Oriented Programming or some request middleware, but in the end I was able to leverage an existing "request builder" pattern that was in use already in the application.